SYN Cookies are the key element of a technique used to guard against SYN flood attacks. Daniel J. Bernstein, the technique's primary inventor, defines SYN Cookies as "particular choices of initial TCP sequence numbers by TCP servers." In particular, the use of SYN Cookies allows a server to avoid dropping connections when the SYN queue fills up. Instead, the server behaves as if the SYN queue had been enlarged. The server sends back the appropriate SYN+ACK response to the client but discards the SYN queue entry. If the server then receives a subsequent ACK response from the client, the server is able to reconstruct the SYN queue entry using information encoded in the TCP sequence number.
Contents |
In order to initiate a TCP connection, the client sends a TCP SYN packet to the server. In response, the server sends a TCP SYN+ACK packet back to the client. One of the values in this packet is a sequence number, which is used by the TCP protocol to reassemble the data stream. According to the TCP specification, that first sequence number sent by an endpoint can be any value as decided by that endpoint. SYN Cookies are initial sequence numbers that are carefully constructed according to the following rules:
The initial TCP sequence number, i.e. the SYN Cookie, is computed as follows:
(Note: since m must be encoded using 3 bits, the server is restricted to sending up to 8 unique values for m when SYN Cookies are in use.)
When a client sends back a TCP ACK packet to the server in response to the server's SYN+ACK packet, the client MUST (according to the TCP spec) use n+1 in the packet's Acknowledgement number, where n is the initial sequence number sent by the server. The server then subtracts 1 from the acknowledgement number to reveal the SYN Cookie sent to the client.
The server then performs the following operations.
From this point forward, the connection proceeds as normal.
The use of SYN Cookies does not break any protocol specifications, and therefore should be compatible with all TCP implementations. There are, however, three caveats that take effect when SYN Cookies are in use. First, the server is limited to only 8 unique MSS values, as that's all that can be encoded in 3 bits. Second, the server must reject all TCP options (such as large windows), because the server discards the SYN queue entry where that information would otherwise be stored. Third, a connection may freeze when the final ACK of the three-way handshake is lost and the client first awaits data from the server (i.e. client has completed the three-way handshake, server did not receive the client's ACK and thus has not actually opened the connection). [1]
While these restrictions necessarily lead to a sub-optimal experience, their effect is rarely noticed by clients. Furthermore, these restrictions need only apply when the server is under attack, and the connection would have otherwise been denied. In such a situation, the loss of a few of the more esoteric options in order to save the connection is usually a reasonable compromise. Version 2.6.26 of the Linux kernel added limited support of TCP options, by encoding them into the timestamp.[2]
The newer TCP Cookie Transactions (TCPCT) standard is designed to overcome these shortcomings of SYN cookies and improve it on a couple of aspects. Unlike SYN cookies, TCPCT is a TCP extension and requires support from both endpoints.
The technique was created by Daniel J. Bernstein and Eric Schenk in September 1996. The first implementation for SunOS was released by Jeff Weisberg a month later, and Eric Schenk released his Linux implementation in February 1997 (the current implementation uses e.g. net.ipv4.tcp_syncookies).